Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.002

Internet Message Format | 1994-06-09 | 88KB

From: [e-mail] (Francois Pottier)
Subject: CSMP Digest, issue 2
Date: Sat, 12 Mar 94 16:36:28 MET

C.S.M.P. Digest             Sat, 12 Mar 94       Volume 3 : Issue 2

Today's Topics:

        Any demo code using PowerPlant out there?
        Converting Str255 to float
        Creating-removing alias files
        Help! Mac Dialog Box Questions
        PackBits for resource compression?
        Problems with serial routines on AV Macs?
        Universal Headers vs. Old Headers
        Using handles to purged-unloaded resources
        Using the serial ports as an input for a SPDT switch.
        WDEF Problems, driving me crazy...
        ZcbFree Goes Negative (Error Number 33)
        any good magazines?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Michael R. Tuzi)
Subject: Any demo code using PowerPlant out there?
Date: 24 Feb 1994 19:53:51 GMT
Organization: University of Maryland College Park

Can some kind soul out there help me with Powerplant??  I bought the
Metrowerks CodeWarrior Bronze CD BECAUSE it supposedly came with a
useful, real C++ class library for handling Macintosh UI items.

Up until now, I have been unable to do a damn thing with it since
it requires Resourcerer to create the PObj resources that everything
is built on, and there appears to be NO way to build the class
components any other way. (I know about the constructor, but it is
SEVERELY limited, in that it can only place the most rudimentary
objects into a window (ie buttons, captions, etc)).

If anyone out there has any samples or pieces of code demonstrating
how I can use this thing, I'd appreciate it if you could send me a copy
via email (I'll post a summary if there is any interest.)  Otherwise
I guess I'll have to wait another couple of years until a usable class
library comes along (and don't flame me about Symantec C++ and the TCL;
I have it and can't even get it to run on my 660 :-[).

------------------------------------------------------------------------------
[e-mail]                  |                #include <innane_saying.h>
------------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Keith Bagley)
Date: 24 Feb 1994 20:27:19 GMT
Organization: Hewlett-Packard

In article <2kj0kf$[e-mail]> [e-mail] (Michael R. Tuzi) writes:
>Can some kind soul out there help me with Powerplant??  I bought the
>Metrowerks CodeWarrior Bronze CD BECAUSE it supposedly came with a
>useful, real C++ class library for handling Macintosh UI items.
>
>Up until now, I have been unable to do a damn thing with it since
>it requires Resourcerer to create the PObj resources that everything
>is built on, and there appears to be NO way to build the class
>components any other way. (I know about the constructor, but it is
>SEVERELY limited, in that it can only place the most rudimentary
>objects into a window (ie buttons, captions, etc)).
>
>If anyone out there has any samples or pieces of code demonstrating
>how I can use this thing, I'd appreciate it if you could send me a copy
>via email (I'll post a summary if there is any interest.)  Otherwise
>I guess I'll have to wait another couple of years until a usable class
>library comes along....                     ^^^^^
                         ????? Years ????

Uh...isn't CodeWarrior still Alpha/Beta? I just got my Development Release
DR1 a couple of weeks ago. I bought it with the understanding that everything
wasn't finished yet, and won't be finished until May sometime. I don't
speak for Metrowerks (Shoot, I rarely speak for HP! :-)) but I think they're
committed to having full functionality for what they've promised in the
Final Release in May.
I'm not trying to get into your head, but you sound like you feel cheated
in some way; you KNEW the software was pre-release when you bought it.
I doubt seriously that you'll have to wait YEARS for a usable class library.
Even if PowerPlant doesn't suit your needs, there are other native-C++
frameworks (StarView, Zinc, etc...) either here now or almost ready to
ship.

Keith

+-------------------------------------------------------------------+
|  |\    /|   .---.             |       Keith Bagley                |
|  | \  / |  /        \     /   |       Hewlett-Packard Company     |
|  |  \/  |  \..       \   /    |       Medical Systems Division    |
|  |      |      \      \ /     |       175 Wyman Street            |
|                /       |      |       Waltham, MA                 |
|            ---'        |      |       [e-mail]   |
+-------------------------------------------------------------------+




+++++++++++++++++++++++++++

>From [e-mail] (Michael R. Tuzi)
Date: 24 Feb 1994 21:22:12 GMT
Organization: University of Maryland College Park


( Tried to mail this to you, but our mailer bounced it back. )

Keith:

If I sounded like I was whining, that was not my intent.  I realized
when I purchased CodeWarrior that it was a alpha/beta release and as
such, some things would not be available.  I didn't expect that the
framework would be completely unusable. (Alpha/Beta to me means that
the basic functionality of the program is in place, but bugs need to
be worked out and missing features need to be added).  If it was
necesssary for a developer to buy another piece of software to use
this product, at least we could have been warned in advance (then I'd've
waited rather than frustrate myself even further).

It appears to me from looking at the framework that it has a sound
conceptual base, but without docs/examples/or the constructor, it
cannot be used.  Maybe I'm being pessimistic, but I think it will be
difficult for MW to get Powerplant ready for commercial release by the
time they've stated.

As for the years of waiting for a usable class library, I've already
waited several (from the time that TCL came out, until the announcement
of Powerplant :-)).

I sincerely hope that I'm wrong on this, because the sole reason that
I purchased CW was to get Powerplant. I'd be severely disappointed to
have wasted another $200 on a development environment I can't use a la
TCL.

+++++++++++++++++++++++++++

>From [e-mail] (Mr_G._Landweber_student_tel_2-73550)
Date: 24 Feb 1994 23:20:13 GMT
Organization: (none)

   In article <2kj0kf$[e-mail]> [e-mail] (Michael R. Tuzi) writes:
   >Can some kind soul out there help me with Powerplant??  I bought the
   >Metrowerks CodeWarrior Bronze CD BECAUSE it supposedly came with a
   >useful, real C++ class library for handling Macintosh UI items.
   >
   >Up until now, I have been unable to do a damn thing with it since
   >it requires Resourcerer to create the PObj resources that everything
   >is built on, and there appears to be NO way to build the class
   >components any other way. (I know about the constructor, but it is
   >SEVERELY limited, in that it can only place the most rudimentary
   >objects into a window (ie buttons, captions, etc)).

I saw a demo of Code Warrior and PowerPlant yesterday, and the version
I saw came with a type of "interface builder" whose main purpose was
to construct and edit those "PObj" resources.  I watched the
demonstrator create a dialog box with a number of buttons, text items,
and other controls all in a matter of minutes without having to change
any code.  This was a demo of Code Warrior gold, and it may have been
a more recent release than what you were using.

-- Greg
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Fri, 25 Feb 1994 00:35:44 -0800
Organization: Internet for the Olympic Peninsula

In article <2kj5q4$[e-mail]>, [e-mail] (Michael
R. Tuzi) wrote:

>
> ( Tried to mail this to you, but our mailer bounced it back. )
>
> Keith:
>
> If I sounded like I was whining, that was not my intent.  I realized
> when I purchased CodeWarrior that it was a alpha/beta release and as
> such, some things would not be available.  I didn't expect that the
> framework would be completely unusable. (Alpha/Beta to me means that
> the basic functionality of the program is in place, but bugs need to
> be worked out and missing features need to be added).  If it was
> necesssary for a developer to buy another piece of software to use
> this product, at least we could have been warned in advance (then I'd've
> waited rather than frustrate myself even further).

It is true that "Constructor" isn't done yet.  It's not true that it is
unusable (although the parts that aren't done clearly can't be used).
Resourceror is one solution.  So is writing Rez code, which can describe
those resources quite well (and tediously).

And...DRn (particularly where n=1) doesn't imply Alpha or Beta...it implies
Development.  Some parts of DR1 are alpha, some are development.
--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 25 Feb 1994 15:30:28 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

>> If I sounded like I was whining, that was not my intent.  I realized
>> when I purchased CodeWarrior that it was a alpha/beta release and as
>> such, some things would not be available.  I didn't expect that the
>> framework would be completely unusable. (Alpha/Beta to me means that
>> the basic functionality of the program is in place, but bugs need to

No. The only thing labelled as Alpha is the C compiler; the
framework and C++ compilers are labelled as development versions.
The usual designation for d/a/b/fc is that:
"d" shouldn't really get outside of development, or an initiated QC
    department
"a" is a version where what's in there is as debugged as the programmers
    can make it, but still not feature complete
"b" is where you are almost feature-complete, QC has had a whack at it,
    and it's time for a more general public and diverse usage situations
    to take over testing.
"fc" is when you're trying to get it out the door, and want to have a
   safety line on to guard against things slipping through the cracks.
   Usually it works like "when fc has gone a week without complaints,
   we ship it without further changes."

So, you got what you bought (some d and a releases) and I think it's
been a terriffic value; porting from SC++ to CW was SO much faster
thanks to the fast re-compile time; then going to the Apple SDK for
actual code production was not so painful since CW took care of 99%
of the conversion process.

--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
 Obsolete (n) - dependable, affordable, readily available
 Support trailing-edge technology!
                    -- Bruce H. McIntosh

+++++++++++++++++++++++++++

>From [e-mail] (Philip Borenstein)
Date: Fri, 25 Feb 1994 18:41:28 GMT
Organization: (none)

[e-mail] (Michael R. Tuzi) writes:

>Can some kind soul out there help me with Powerplant??  I bought the
>Metrowerks CodeWarrior Bronze CD BECAUSE it supposedly came with a
>useful, real C++ class library for handling Macintosh UI items.

>Up until now, I have been unable to do a damn thing with it since
>it requires Resourcerer to create the PObj resources that everything
>is built on, and there appears to be NO way to build the class
>components any other way.

Unfortunately, the PObj format can't be descriped in Rez. DR2 will use a
slightly different format that's Rez-able. Even as we speak, Greg Dow is
writing constructors that let you build UI objects on the fly.

Hold on.

--philip.
  [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Doug Williams)
Date: 25 Feb 1994 19:59:29 GMT
Organization: University of Arizona, Tucson, AZ

[e-mail] (Michael R. Tuzi) writes:

>Can some kind soul out there help me with Powerplant??  I bought the
>Metrowerks CodeWarrior Bronze CD BECAUSE it supposedly came with a
>useful, real C++ class library for handling Macintosh UI items.

>Up until now, I have been unable to do a damn thing with it since
>it requires Resourcerer to create the PObj resources that everything
>is built on, and there appears to be NO way to build the class
>components any other way.


A similar problem is keeping me from buying CodeWarrior as well: the huge
amounts of PD code written in ThinkC. I have seen the BareBones converter
program (ThinkC project -> CodeWarrior), but wonder how much of the _code_ out
there is somehow ThinkC dependent.  Has anyone successfully compiled the
WinterShell, TransSkel, or MacStarter projects under CodeWarrior?  If so, what
changes (if any) had to be made to the code?  If the changes turn out to be
minimal or (overly optimistically) nonexistant, I'll order CodeWarrior right
after I get my CDRom drive.

    For example, the code fragment recently posted by Robert Mah about how
to write mixed 68K C, PowerPC C and 68K assembly in both the Metrowerks and
Symantec environments showed that the environments are very close, but not
exactly the same.


I'll try to summarize any info that comes my way, but I obviously won't be
able to test any CodeWarrior code.

Doug Williams
[e-mail]

no .sig

+++++++++++++++++++++++++++

>From E.J. Draper <[e-mail]>
Date: 25 Feb 1994 22:59:25 GMT
Organization: U.T.M.D. Anderson Cancer Center

In article <2kllb1$[e-mail]> Doug Williams,
[e-mail] writes:
>    For example, the code fragment recently posted by Robert Mah about how
>to write mixed 68K C, PowerPC C and 68K assembly in both the Metrowerks
and
>Symantec environments showed that the environments are very close, but
not
>exactly the same.

Why is that such a big deal?  THINK/Sym C and MPW C have always been
different.

IMHO, if someone is unable/unwilling to modify a code snippet to suit the
needs of their preferred compiler, they should think twice before using
the snippet.


      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             [e-mail]

---------------------------

>From [e-mail] (Greg Vaughn)
Subject: Converting Str255 to float
Date: Wed, 23 Feb 94 15:37:57 GMT
Organization: Insulator Lab Texas Tech U. Physics

I'm looking for a way to convert and editable text item in a dialog box,
which is read as a Str255 into a float (actually a double, but I can
typecast that from a float) to use in calculations. Has anyone seen any
code snippet that will do this in C? I'd appreciate any pointers anyone
might have.

   ______
  /\__  _\                  | Greg Vaughn
  \/_/\ \/  exas            | Grad Student, Dept. of Physics
     \ \_\  ech University  | Insulator Research Laboratory
      \/_/  Lubbock, Texas  | E-Mail: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Scott M. Silver)
Date: 23 Feb 1994 21:47:07 GMT
Organization: Dartmouth College - Hanover, NH

In article <[e-mail]>
[e-mail] (Greg Vaughn) writes:

> I'm looking for a way to convert and editable text item in a dialog box,
> which is read as a Str255 into a float (actually a double, but I can
> typecast that from a float) to use in calculations. Has anyone seen any
> code snippet that will do this in C? I'd appreciate any pointers anyone
> might have.

The way I usually do this is do a P2CStr, and then atof (convert ascii
to float), or atod (convet ascii to double). In english: Convert to a
CStr, and then use ANSI library functions to convert it into the right
kind of number.

I remember a while back a threads flaming everyone about ineffieciency
etc.  This is just one simple way of doing it.

Scott
____________________________________________________________________
Scott Silver            Dartmouth College                Hanover, NH

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Wed, 23 Feb 1994 17:52:01 -0600
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail]
(Greg Vaughn) wrote:

>I'm looking for a way to convert and editable text item in a dialog box,
>which is read as a Str255 into a float (actually a double, but I can
>typecast that from a float) to use in calculations. Has anyone seen any
>code snippet that will do this in C? I'd appreciate any pointers anyone
>might have.

The best way to do it is use FormatStr2X, especially if you are taking the
input from a dialog box. The nice thing about FormatStr2X is that it even
works in funky foreign language scripts like Chinese. To use the routine,
you must pass it not only the Str255 that you want converted, but also the
results of the Str2Format routine and the GetItlTable routine. The
documentation is generally poor, so I'll describe the parameters and give
you a code example below. Here's what you pass to FormatStr2X:

source:       Obviously the string representation of the number.

myCanonical:  This is simply the format that you expect the number to be.
              For example, if you wanted a positive integer with up to
              3 decimal places, you would want the format to be "###".
              The "#" symbol means a non-zero filled digit, whereas a
              "0" would mean zero filled. If you wanted an floating point
              exponential notation with up to 2 digit integer portion,
              exactly 2 digit decimal portion, and exactly 1 digit after
              the "E", your format would be "##.00E+0". In a format
              string, you can put the format for a positive value, a
              negative value, and 0 seperated by semicolons:
                     ##.00E+0;-##.00E+0;0.00E+0

              But myCanonical is not the format string itself, but is an
              internal format that you get from calling Str2Format. This
              is so you can store the format returned to you by Str2Format
              and use it on different international systems.

partsTable:   The number parts table from the 'itl4' resource. If you are
              using System 7 or later, you can simply call IUGetItlTable,
              asking it for the number parts table. You don't need to
              worry about HLock'ing itlHandle because FormatStr2X doesn't
              move memory; just don't do anything between your call to
              IUGetItlTable and the FormatStr2X routine. If you are using
              System 6, you need to perform the IUGetItlTable by hand.
              It's a few lines of code; if need it, I can write up some
              code. The extended number to put the thing into. Most C
              compilers will convert it to a float on the fly.

So, let's say you expect the user to enter a string containing up to 5
digits in the integer with a thousand marker between the 3rd and fourth
digit, exactly two digits after the decimal, put it in parenthesis if it's
negative, and have it just be "0.00" if it's 0. (I will use "." for the
decimal and "," for the thousand marker.) Here's the C code (passing in
the source string):

Handle itlHandle;             /* The 'itl4' resource handle */
long offset, length;          /* Offset and length of parts table */
NumFormatString myCanonical;  /* Canonical format */
extended x;                   /* The number to put it into */

IUGetItlTable(iuCurrentScript, iuNumberPartsTable,
              &itlHandle, &offset, &length);
Str2Format("\p##,###.00;(##,###.00);0.00",
           (NumberParts *)(*itlHandle + offset),
           &myCanonical);
FormatStr2X(source, &myCanonical,
            (NumberParts *)(*itlHandle + offset), &x);

The FormatStr2X routines will return a result that will tell you if there
are any parsing errors and to what level of confidence it thinks it parsed
it correctly.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Pete Resnick)
Date: Wed, 23 Feb 1994 17:31:21 -0600
Organization: University of Illinois at Urbana-Champaign

In article <[e-mail]>, [e-mail]
(Greg Vaughn) wrote:

>I'm looking for a way to convert and editable text item in a dialog box,
>which is read as a Str255 into a float (actually a double, but I can
>typecast that from a float) to use in calculations. Has anyone seen any
>code snippet that will do this in C? I'd appreciate any pointers anyone
>might have.

The best way to do it is use FormatStr2X, especially if you are taking the
input from a dialog box. The nice thing about FormatStr2X is that it even
works in funky foreign language scripts like Chinese. To use the routine,
you must pass it not only the Str255 that you want converted, but also the
results of the Str2Format routine and the GetItlTable routine. The
documentation is generally poor, so I'll describe the parameters and give
you a code example below. Here's what you pass to FormatStr2X:

source:       Obviously the string representation of the number.

myCanonical:  This is simply the format that you expect the number to be.
              For example, if you wanted a positive integer with up to
              3 decimal places, you would want the format to be "###".
              The "#" symbol means a non-zero filled digit, whereas a
              "0" would mean zero filled. If you wanted an floating point
              exponential notation with up to 2 digit integer portion,
              exactly 2 digit decimal portion, and exactly 1 digit after
              the "E", your format would be "##.00E+0". In a format
string,
              you can put the format for a positive value, a negative
value,
              and 0 seperated by semicolons: "##.00E+0;-##.00E+0;0.00E+0"

              But myCanonical is not the format string itself, but is an
              internal format that you get from calling Str2Format. This
              is so you can store the format returned to you by Str2Format
              and use it on different international systems.

partsTable:   The number parts table from the 'itl4' resource. If you are
              using System 7 or later, you can simply call IUGetItlTable,
              asking it for the number parts table. You don't need to
              worry about HLock'ing itlHandle because FormatStr2X doesn't
              move memory; just don't do anything between your call to
              IUGetItlTable and the FormatStr2X routine. If you are using
              System 6, you need to perform the IUGetItlTable by hand.
It's
              a few lines of code; if need it, I can write up some code.

x:            The extended number to put the thing into. Most C compilers
              will convert it to a float on the fly.

So, let's say you expect the user to enter a string containing up to 5
digits in the integer with a thousand marker between the 3rd and fourth
digit, exactly two digits after the decimal, put it in parenthesis if it's
negative, and have it just be "0.00" if it's 0. (I will use "." for the
decimal and "," for the thousand marker.) Here's the C code (passing in
the source string):

Handle itlHandle;             /* The 'itl4' resource handle */
long offset, length;          /* Offset and length of number parts table
*/
NumFormatString myCanonical;  /* Canonical format */
extended x;                   /* The number to put it into */

IUGetItlTable(iuCurrentScript, iuNumberPartsTable,
              &itlHandle, &offset, &length);
Str2Format("\p##,###.00;(##,###.00);0.00",
           (NumberParts *)(*itlHandle + offset),
           &myCanonical);
FormatStr2X(source, &myCanonical, (NumberParts *)(*itlHandle + offset),
&x);

The FormatStr2X routines will return a result that will tell you if there
are any parsing errors and to what level of confidence it thinks it parsed
it correctly.

pr
--
Pete Resnick        (...so what is a mojo, and why would one be rising?)
Graduate assistant - Philosophy Department, Gregory Hall, UIUC
System manager - Cognitive Science Group, Beckman Institute, UIUC
Internet: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Graham Cox)
Date: Thu, 24 Feb 1994 15:34:41 GMT
Organization: School of Information Systems, UEA, Norwich

In article <[e-mail]>,
[e-mail] (Pete Resnick) wrote:

> In article <[e-mail]>, [e-mail]
> (Greg Vaughn) wrote:
>
> >I'm looking for a way to convert and editable text item in a dialog box,
> >which is read as a Str255 into a float (actually a double, but I can

Why not just use SANE's Str2Num procedure?

--------------------------------------------------------------------------
Love & BSWK, Graham

-Everyone is entitled to their opinion, no matter how wrong they may be...
--------------------------------------------------------------------------

---------------------------

>From [e-mail] (Mike Davis, Chief of Operations -- KCGL)
Subject: Creating-removing alias files
Date: 24 Feb 1994 23:33:41 GMT
Organization: The Ohio State University


    I would very much like to create and remove an alias file on the
desktop via a program.  The basic idea is to provide a hint to the current
Mac user that (s)he needs to disconnect from a service by displaying an alias
to the program which allows him/her to (dis)connect with his/her name instead
of "program-name alias".  When the user does disconnect, the alias file is
removed from the desktop.  I've looked through a number of (N)IM volumes, but
all I can find reference to are alias _records_ and manipulating same.
Apparently, creating alias _files_ isn't recommended, but I'd like to do it
anyway (;-), unless someone can offer a better method of constantly notifying
the user that (s)he needs to disconnect before leaving the Mac.

                            Thanks,
                             Mike
--
 Internet: [e-mail] |
            -or- [e-mail]           |   These Thoughts, They Be Mine
   BITNET: [e-mail]         |

+++++++++++++++++++++++++++

>From [e-mail] (John Mah)
Date: Fri, 25 Feb 1994 02:51:02 GMT
Organization: University of Waterloo

Basically, you want to create a resource file of type 'alis' & creator 'fndr',
stuff a AliasHandle (generated by a call to NewAlias()) into a resource of
type 'alis' with resource ID of 0. Make sure to set the 'alias' bundle bit of
the created file.

Here's a sample code snippet taken from one of my programs (adjust to suit
to your tastes):

---- begin snippet ----

    AliasHandle    hArticle;
    OSErr        err;
    FInfo        fndrInfo;
    FSSpec        articleSpec;
    short        refNum;
    FSSpec        newsFolderFS;

        // Create minimal alias for the original article.

    newsFolderFS.vRefNum = gSpoolFolder->fldrVRefNum;
    newsFolderFS.parID = gSpoolFolder->fldrDirID;
    newsFolderFS.name[0] = '\0';

    err = NewAlias( &newsFolderFS, theSpec, &hArticle );
    if ( !hArticle || err != noErr ) {
        LogError( "Could not allocate alias for article!" );
        return;
    }

        // Setup the article file, initialize it and specify where it is
        // supposed to be put. If it exists, then delete it.

    FSMakeFSSpec( gSpoolFolder->fldrVRefNum, entry->dirID,
        (StringPtr) articleNumber, &articleSpec );
    FSpCreateResFile( &articleSpec, 'fndr', 'alis', 0 );
    err = ResError();
    if ( err == dupFNErr ) {
        err = FSpDelete( &articleSpec );
        FSpCreateResFile( &articleSpec, 'fndr', 'alis', 0 );
        err = ResError();
    }
    if ( err != noErr ) {
        LogError( "Couldn't create alias file!" );
        return;
    }

        // Create the resource file and open it for writing.

    refNum = FSpOpenResFile( &articleSpec, fsWrPerm );
    if ( refNum == -1 || ResError() != noErr ) {
        LogError( "Couldn't open an alias file!" );
        return;
    }

        // Write alias resource to file.

    AddResource( (Handle) hArticle, 'alis', 0, "\p" );
    ChangedResource( (Handle) hArticle );
    if ( ResError() == noErr ) {
        WriteResource( (Handle) hArticle );
        HPurge( (Handle) hArticle );
    }

    CloseResFile( refNum );

        // Now set the "alias" finder bit.

    FSpGetFInfo( &articleSpec, &fndrInfo );
    fndrInfo.fdFlags |= (1L << 15);
    FSpSetFInfo( &articleSpec, &fndrInfo );

---- end snippet ----

Hope that gives you an idea of how things work.

- John


---------------------------

>From [e-mail] (Chris Severtson)
Subject: Help! Mac Dialog Box Questions
Date: Tue, 22 Feb 1994 16:58:10 GMT
Organization: Microware Systems Corp., Des Moines, Iowa

I am not sure if this is the correct group to post to, but here goes...

Dialog Box Questions:
-------------------
1) The toolbox call HiliteControl() can be used to dim a control and its
title. I am desperately in search of a way to "dim" statText and editText
dialog items.

2) I am also searching for the answer to this question: I use the call
SetDialogDefaultItem() and HiliteControl() to mark my "OK" button as the
default button and set it to be initially "dim". ModalDialog() hilites this
button even though I "dimmed" it before calling it. After the first time
through the loop though, it will stay dimmed if I dim it again. I think it
has to do with the fact that it is the first call and ModalDialog() has to
draw the window. What I am looking for is a workaround.

Any help you can offer is greatly appreciated.  Please email me your
responses.

+++++++++++++++++++++++++++

>From [e-mail] (Jim Walker)
Date: 22 Feb 1994 19:11:31 GMT
Organization: University of South Carolina - Columbia - Computer Science

[e-mail] (Chris Severtson) writes:

>1) The toolbox call HiliteControl() can be used to dim a control and its
>title. I am desperately in search of a way to "dim" statText and editText
>dialog items.

I posted some text item dimming source code (THINK C) at the ftp site
bigbird.csd.scarolina.edu, pub/mac.
--

 -- Jim Walker  USC Dept. of Math.  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert S. Mah)
Date: Tue, 22 Feb 1994 16:00:59 -0500
Organization: One Step Beyond

[e-mail] (Chris Severtson) wrote:

> 1) The toolbox call HiliteControl() can be used to dim a control and its
> title. I am desperately in search of a way to "dim" statText and editText
> dialog items.

Just draw a 50% gray pattern over the text in srcBic mode.  If you wanna
get fancy and use Color QD, use the blend mode.  Note that, you'll have to
apply these in your filter proc because a screen depth change or an update
on the dialog will cause the item text to redraw itself in 100% black.

For finer control, draw the static text using a userItem proc.  If you do
this, and are running only on System 7, you can use the new grayishTextOr
(or something like that) drawing mode to draw diabled text items.

Finally, "dimming" editable text items is no harder than static text items.
 However, the primary problem is with making dialog manager skip these
items during the tabbing sequence.

I believe there is a code snippet (available on the reference library CD's
and on ftp.apple.com in /dts/mac/sc/snippets/toolbox/, called "Dialog Bits"
by C.K. Haun that illustrates how to do both these things.


> 2) I am also searching for the answer to this question: I use the call
> SetDialogDefaultItem() and HiliteControl() to mark my "OK" button as the
> default button and set it to be initially "dim". ModalDialog() hilites this
> button even though I "dimmed" it before calling it. After the first time
> through the loop though, it will stay dimmed if I dim it again. I think it
> has to do with the fact that it is the first call and ModalDialog() has to
> draw the window. What I am looking for is a workaround.

One way that might work is to open and draw the dialog box offscreen first.
 Then dim the control.  Then move it to the correct location and then start
your ModalDialog loop.  I haven't tried this myself, so take this advice
with a grain of salt.

Cheers,
Rob
________________________________________________________________________
 Robert S. Mah              One Step Beyond              [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Graham Cox)
Date: Fri, 25 Feb 1994 12:44:19 GMT
Organization: School of Information Systems, UEA, Norwich

In article <[e-mail]>, [e-mail]
(Robert S. Mah) wrote:

> [e-mail] (Chris Severtson) wrote:
>
>
> Finally, "dimming" editable text items is no harder than static text items.
>  However, the primary problem is with making dialog manager skip these
> items during the tabbing sequence.
>

You can 'cast' a stat text item to an edit text one and vice versa- the
handle to the item is the same. The dialog manager then automatically skips
the item. However, you have to check before changing the type that it's not
the currently selected item- if it is (by comparing the ID to the value in
the dialog record) then change the selection to another field first. Its
much easier to do than describe- one of my dialogs in MacTriv (archive
sites) illustrates this behaviour.



--------------------------------------------------------------------------
Love & BSWK, Graham

-Everyone is entitled to their opinion, no matter how wrong they may be...
--------------------------------------------------------------------------

---------------------------

>From AIKEN <[e-mail]>
Subject: PackBits for resource compression?
Date: Fri, 25 Feb 1994 02:46:07 GMT
Organization: McGill University

    Is PackBits suitable for use as a general-purpose compression
algorithm for data which is known to be highly redundant? THINK
Reference speaks of its use for compressing B&W bitmap images, since
they tend to contain large solid areas, but is there any reason it
couldn't be used for other purposes? How fast is it?

    Mark Aiken
    [e-mail]


+++++++++++++++++++++++++++

>From [e-mail]
Date: 25 Feb 1994 20:23:08 GMT
Organization: Oberlin College

In article  <[e-mail]> AIKEN
<[e-mail]> writes:

>
>     Is PackBits suitable for use as a general-purpose compression
> algorithm for data which is known to be highly redundant? THINK
> Reference speaks of its use for compressing B&W bitmap images, since
> they tend to contain large solid areas, but is there any reason it
> couldn't be used for other purposes? How fast is it?
>
>     Mark Aiken
>     [e-mail]
>

Packbits is also suitable for 8-bit color (PICT's automatically use packbits
when bitmap information is stored), and I think that there also simple
compression schemes for 16 and 32 bit color as well.

Packbits uses run length encoding to compress data.  That is, if there are 3 or
more identical BYTES in a row, it will encode into 2 bytes, where the first
byte is the count (of identical bytes) and the second is the byte itself. (it's
a little more complex than this, but this is the general idea.  But be aware
that there is more overhead than just this).  If there are less than three
identical consecutive bytes, no compression takes place.

So, whether or not PackBits is good for your purpose, it  is if you have
massive repetition of 1,2,4, or 8 bit patterns - and the repetition is
consecutive.  For text, packbits is pretty useless.  But, it is a general
routine - it is also lossless (data is preserved exactly) so if you have data
that fits the above criteria, use it.

-matt


---------------------------

>From [e-mail] (Ingemar Ragnemalm)
Subject: Problems with serial routines on AV Macs?
Date: Fri, 25 Feb 1994 10:52:59 GMT
Organization: (none)


I'm posting this for a friend. He has some working serial routines, just
the ordinary stuff. When he used that, in a MacroMedia Director plug-in,
on an AV Mac, it crashed, and so did MacroMedias demo sources. (Their
*compiled* module did work, though, so we guess that is a newer version.)

Is there something we need to know when using the serial ports on AV Macs?


--
---
Ingemar Ragnemalm, PhD
Image processing, Mac shareware games
E-mail address: [e-mail] or [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Mike Cohen)
Date: Fri, 25 Feb 1994 18:49:28 GMT
Organization: ISIS International

[e-mail] (Ingemar Ragnemalm) writes:


>I'm posting this for a friend. He has some working serial routines, just
>the ordinary stuff. When he used that, in a MacroMedia Director plug-in,
>on an AV Mac, it crashed, and so did MacroMedias demo sources. (Their
>*compiled* module did work, though, so we guess that is a newer version.)

>Is there something we need to know when using the serial ports on AV Macs?

Someone reported that to me. I have some code that opens the serial driver &
it fails on an AV mac. One work around seems to be to use the CTB and the
Serial Tool instead (although you'll proably start getting calls "why doesn't
it work - it says tool not found"). Unfortunately, I don't have access to an
AV for testing right now - my client's building was destroyed last month.

>--
>---
>Ingemar Ragnemalm, PhD
>Image processing, Mac shareware games
>E-mail address: [e-mail] or [e-mail]
--
Mike Cohen - [e-mail]
NewtonMail: MikeC49506 / ALink: D6734 / AOL: MikeC20


+++++++++++++++++++++++++++

>From [e-mail] (Bruce Goldstein)
Date: Fri, 25 Feb 1994 10:47:57 -0700
Organization: Jet Propulsion Laboratory

In article <[e-mail]>, [e-mail] (Ingemar
Ragnemalm) wrote:

>
> I'm posting this for a friend. He has some working serial routines, just
> the ordinary stuff. When he used that, in a MacroMedia Director plug-in,
> on an AV Mac, it crashed, and so did MacroMedias demo sources. (Their
> *compiled* module did work, though, so we guess that is a newer version.)
>
> Is there something we need to know when using the serial ports on AV Macs?
>
>
> --
> ---
> Ingemar Ragnemalm, PhD
> Image processing, Mac shareware games
> E-mail address: [e-mail] or [e-mail]
You should get the AV Serial Extension (unsupported Apple software).
It is available somewhere on sumex-aim.stanford.edu

---------------------------

>From Willie Rauchwerger <[e-mail]>
Subject: Universal Headers vs. Old Headers
Date: 22 Feb 1994 15:38:44 GMT
Organization: OU Health Sciences Center

Well, I was in the process of porting my program from
Think C 6.0 to Metrowerks C++ 68k, and I ran into a little
inconsistency with the Universal Header files and the old
Think includes, and when I checked, the old MPW includes.

(Note how the the first argument is defined.)

In the Think headers, "ToolUtils.h":
pascal void GetIndPattern(Pattern thePat,
                          short patternListID, short index);

In the old MPW headers, "ToolUtils.h":
pascal void GetIndPattern(Pattern thePat,
                          short patternListID, short index);

But in the Metrowerks headers (Apple Universal Headers), "ToolUtil.h":
extern pascal void GetIndPattern(Pattern *thePat,
                          short patternListID, short index);

And the Mac on RISC SDK headers (Apple Universal Headers) "ToolUtil.h":
extern pascal void GetIndPattern(Pattern *thePat,
                          short patternListID, short index);

All of this brings up several questions:

1. Is this inconsistency a plain mistake?
2. If not, is it because of the PPC C compilers ignoring
    the pascal keyword calling conventions?
3. If so (#2), how do I maintain the same set of source for
    Think and for Metrowerks?
    (I can't completely commit to MW, the debugger is too flaky.)

Help, anyone...thanks.


Willie Rauchwerger          AppleLink: Willie
Telemedicine Software Guy   Internet: [e-mail]
OU Health Sciences Center

+++++++++++++++++++++++++++

>From [e-mail] (Jon W‰tte)
Date: 23 Feb 1994 07:58:53 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

In <2kd8u4$[e-mail]> Willie Rauchwerger <[e-mail]> writes:

>In the old MPW headers, "ToolUtils.h":
>pascal void GetIndPattern(Pattern thePat,

>But in the Metrowerks headers (Apple Universal Headers), "ToolUtil.h":
>extern pascal void GetIndPattern(Pattern *thePat,

>1. Is this inconsistency a plain mistake?

No. "Pattern" changed from unsigned char[8] to a struct two years ago,
but Symantec hasn't kept up with that change yet.
This is a well-documented gotcha when going to the universal headers.
You will have to fins ALL your pattern references and probably change
them, including "gray" which is now written "& qd . gray"

>2. If not, is it because of the PPC C compilers ignoring
>    the pascal keyword calling conventions?

Partly that, and partly because the char-array had some unfortunate
problems.

>3. If so (#2), how do I maintain the same set of source for
>    Think and for Metrowerks?

You make the universal headers work under Think. Good luck!
--
 -- Jon W{tte, [e-mail], Mac Hacker Deluxe --
  "And now, from the makers of EDLIN, comes: Windows NT!"

+++++++++++++++++++++++++++

>From [e-mail] (Jim Browne)
Date: 24 Feb 94 00:23:02 GMT
Organization: University of Illinois at Urbana

[e-mail] (Jon W‰tte) writes:

>In <2kd8u4$[e-mail]> Willie Rauchwerger <[e-mail]> writes:

>>3. If so (#2), how do I maintain the same set of source for
>>    Think and for Metrowerks?

>You make the universal headers work under Think. Good luck!

Do this in your prefix file:

#ifdef THINK_C
#define PATTERN(x) x
#else
#define PATTERN(X) &x
#endif

And then surround your pattern references with PATTERN(   )


--
Jim Browne                                             | [e-mail] |
Head NCSA Mac Telnet Hacker, SDG System Administrator  | [phone]        |
<a href="http://www.ncsa.uiuc.edu/SDG/People/jbrowne/jbrowne.html">Click me</a>
 "People can buy HANDGUNS easier." - S. Anichini, on accquiring IMSA yearbooks.

+++++++++++++++++++++++++++

>From [e-mail] (Pete Hoch x39699)
Date: Wed, 23 Feb 1994 15:53:48 GMT
Organization: Eastman Kodak Company

Willie Rauchwerger ([e-mail]) wrote:
:
: (Note how the the first argument is defined.)
:
: In the old MPW headers, "ToolUtils.h":
: pascal void GetIndPattern(Pattern thePat,
:                           short patternListID, short index);
:
: But the Mac on RISC SDK headers (Apple Universal Headers) "ToolUtil.h":
: extern pascal void GetIndPattern(Pattern *thePat,
:                           short patternListID, short index);
:
: All of this brings up several questions:
:
: 1. Is this inconsistency a plain mistake?

This is not a mistake but it does look funny.

: 2. If not, is it because of the PPC C compilers ignoring
:     the pascal keyword calling conventions?
: 3. If so (#2), how do I maintain the same set of source for
:     Think and for Metrowerks?

Good guess but wrong.  The original development environment for the
Macintosh (which ran on the Lisa for you history bufs.)  passed any
argument which was longer than four bytes by reference.  This is
why you never see Rect in a toolbox argument call but you allways
see Rect*.  Since the Pattern structure (which used to be an array)
is longer than four bytes so it must be passed by reference.  When
Pattern was declaired as an array this happend for you because of
the design on the C language.

Pete


+++++++++++++++++++++++++++

>From [e-mail] (joe zobkiw)
Date: Thu, 24 Feb 1994 18:06:54 GMT
Organization: Datawatch Corporation

Getting the new headers to work under THINK is not a big deal. There are
some exceptions but you can get around them if you need to relatively
easily. I've uploaded a project to AOL that will help you to use the new
Universal Headers with THINK C. That is, if you still want to use THINK C
at all.

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 24 Feb 1994 10:13:57 -0800
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>,
[e-mail] (Pete Hoch x39699) wrote:

The urgency of the change to Pattern was simple:  the old way led to some
crashing situations on 68000 Macs, and Pattern should never have been
defined that way in C.  Too close a copy of the Pascal definition was made
early on.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Thu, 24 Feb 1994 10:09:57 -0800
Organization: Internet for the Olympic Peninsula

In article <2kf2bt$[e-mail]>, [e-mail] (Jon Wtte)
wrote:

> >3. If so (#2), how do I maintain the same set of source for
> >    Think and for Metrowerks?
>
> You make the universal headers work under Think. Good luck!
> --

Which implies that the task is harder than it really is.  Pretty good
instructions on doing the job are included (strangely...the only place I've
seen them) on the AppleScript 1.1 Developer Kit CD.  [Since AS 1.1 has
Universalized headers).]

It was working for me, although I needed to revert to standard (ie, old
fashioned) Think headers to check something out.  I have a nice StuffIt
archive with the modern ones.  I don't care much, since I've almost
entirely switched to CodeWarrior.

--
John Baxter    Port Ludlow, WA, USA  [West shore, Puget Sound]
   [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Aaron Giles)
Date: Thu, 24 Feb 1994 13:55:30 -0500
Organization: Cornell University Medical College

In article <[e-mail]>,
[e-mail] (Chuck Shotton) wrote:

> > >3. If so (#2), how do I maintain the same set of source for
> > >    Think and for Metrowerks?
> >
> > You make the universal headers work under Think. Good luck!
>
> That, or use a few conditional compiles. I have 3 different programs which
> all compile under Think C, Metrowerks C (68k & PPC), and MPW PPC C and the
> total number of #ifdefs to support this amounts to about 3 for each entire
> program. Most of the hassles are with Universal ProcPtrs.

Making the Universal Headers work under THINK is not so hard.  Just turn on
4-bit ints, 8-byte doubles, and put a "#define applec 1" in the THINK C
options pre-compile area.  With the possible exception of numerics, that
makes 99% of it work.

--
Aaron Giles
Macintosh & Newton Developer
Cornell University Medical College
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chuck Shotton)
Date: Thu, 24 Feb 1994 11:32:10 -0600
Organization: Academic Computing, UT-Houston

In article <2kf2bt$[e-mail]>, [e-mail] (Jon Wtte)
wrote:

> >3. If so (#2), how do I maintain the same set of source for
> >    Think and for Metrowerks?
>
> You make the universal headers work under Think. Good luck!

That, or use a few conditional compiles. I have 3 different programs which
all compile under Think C, Metrowerks C (68k & PPC), and MPW PPC C and the
total number of #ifdefs to support this amounts to about 3 for each entire
program. Most of the hassles are with Universal ProcPtrs.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                             \
Assistant Director, Academic Computing     \   "Are we there yet?"
U. of Texas Health Science Center Houston   \
[e-mail]  [phone] \
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-

+++++++++++++++++++++++++++

>From [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 25 Feb 94 11:12:16 +1300
Organization: University of Waikato, Hamilton, New Zealand

In article <2kd8u4$[e-mail]>, Willie Rauchwerger <[e-mail]> writes:
> Well, I was in the process of porting my program from
> Think C 6.0 to Metrowerks C++ 68k, and I ran into a little
> inconsistency with the Universal Header files and the old
> Think includes, and when I checked, the old MPW includes.
>
> (Note how the the first argument is defined.)
>
> In the Think headers, "ToolUtils.h":
> pascal void GetIndPattern(Pattern thePat,
>                           short patternListID, short index);
>
> In the old MPW headers, "ToolUtils.h":
> pascal void GetIndPattern(Pattern thePat,
>                           short patternListID, short index);
>
> But in the Metrowerks headers (Apple Universal Headers), "ToolUtil.h":
> extern pascal void GetIndPattern(Pattern *thePat,
>                           short patternListID, short index);
>
> And the Mac on RISC SDK headers (Apple Universal Headers) "ToolUtil.h":
> extern pascal void GetIndPattern(Pattern *thePat,
>                           short patternListID, short index);
>
> 1. Is this inconsistency a plain mistake?

It looks like a mistake in the first two versions that was corrected in the
last two. In Pascal calling conventions, anything larger than four bytes is
passed by reference, so I guess the incorrect version would actually work
(I've seen the same mistake elsewhere in the interfaces).

Lawrence D'Oliveiro                       fone: [phone]
Info & Tech Services Division              fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00

---------------------------

>From [e-mail] (Dan Griscom)
Subject: Using handles to purged-unloaded resources
Date: Wed, 23 Feb 1994 03:46:25 GMT
Organization: MIT Media Laboratory


I want to delete a humongous resource from a resource file, but I
don't want to load it into memory first. I'd like to be able to do
this:

...
SetResLoad(false);
theRes = Get1NamedResource(theResType, theResName);
SetResLoad(true);
RemoveResource(theRes);
...

Would this be kosher? Is there a better way?

This can be restated as a more general question: can handles to
resources fetched when ResLoad is false (or handles to purged
resources) be used in routines where the resource contents aren't
needed, such as GetResSize, GetResInfo, SetResInfo, etc?

Thanks,
Dan Griscom
Suitable Systems

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Wed, 23 Feb 1994 14:27:21 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (Dan Griscom) writes:
>I want to delete a humongous resource from a resource file, but I
>don't want to load it into memory first. I'd like to be able to do
>this:
>...
>SetResLoad(false);
>theRes = Get1NamedResource(theResType, theResName);
>SetResLoad(true);
>RemoveResource(theRes);
>...
>Would this be kosher? Is there a better way?

This works for me. Just to be sure, however, I'd double check that
the resID is what you expect - since resNames do not have to be
unique, it is possible you end up getting a different resource
>From the one you wanted...

>This can be restated as a more general question: can handles to
>resources fetched when ResLoad is false (or handles to purged
>resources) be used in routines where the resource contents aren't
>needed, such as GetResSize, GetResInfo, SetResInfo, etc?

I cannot attest to every permutation of this, but the ones I've used
(Get/SetResInfo) worked fine.

-Ivan
---
Ivan Cavero Belaunde ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 24 Feb 1994 10:53:44 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Ivan M CaveroBelaunde) writes:

>This works for me. Just to be sure, however, I'd double check that
>the resID is what you expect - since resNames do not have to be
>unique, it is possible you end up getting a different resource
>from the one you wanted...

WHy?  Resource IDs are not unique either, and you don't check them against
the name.  Basically, use the appropriate accessor depending on what you
resource you want.
   Peter.
--
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

---------------------------

>From [e-mail] (Andrew Greenberg)
Subject: Using the serial ports as an input for a SPDT switch.
Date: 21 Feb 1994 23:14:03 GMT
Organization: Reed College,  Portland, Oregon

Hello!

I am attempting to read a simple SPDT microswitch via the serial ports
on Mac SEs and later models.

I'm using CTS (HSKo) as an input, and I need a differential signal (both
+ and - ) to drive the input. The only way I can see to do this is hold
TxD low or high and use the two corresponding differential outputs (TxD+
and TxD-) as the differential signal I need.

I can't find any helpful references as to how to do this; the closest
I've seen is page 360 of the Mac Hardware reference (2nd ed) where it
talks about asserting /RTS. However, I can't find any info on how to do this.

If you have any information on asserting TxD or /RTS, I'd really appreciate
a quick note, or even a referral!
(I'm using Think c 6, BTW).

Thanks!!

Andrew Greenberg
([e-mail])


+++++++++++++++++++++++++++

>From   <a@b.c.d>
Date: Tue, 22 Feb 1994 15:49:50 GMT
Organization:

In article <2kbf7r$[e-mail]> Andrew Greenberg,
[e-mail] writes:

>I am attempting to read a simple SPDT microswitch via the serial ports
>on Mac SEs and later models...

We did something like this a while ago, using the serial port on a IIfx to
connect to a photocopy card reader/decrementer; a very simple machine,
with one input (there is a card with value on it) and one output
(decrement
the card value by one unit).  (This is on a kiosk system in a gallery;
used to
charge for printouts.)

According to my notes (which aren't guaranteed to be accurate) we used a
three wire cable to connect the unit to the Mac, which was connected to
CTS (pin 2?), TxD (3) and GND (4).   The card reader shorted CTS to GND
when the it had a valid card; TxD was either asserted to decrement the
card.  I don't have any information about how CTS was tied high when
not being grounded.

To read the switch, we use:

  #define CAN_PRINT    -1
        if ( iErr = SerStatus( iPortRef, &PortStatus ) )
            ... error stuff
        return( PortStatus.ctsHold == CAN_PRINT );

To decrement the card value, we use
            if ( iErr = SerSetBrk( iPortRef ) )        ... error stuff
            Delay( 10L, &l );
            if ( iErr = SerClrBrk( iPortRef ) )        ... error stuff

My guess from reading your note is that if you wire your switch to flip
CTS between GND and TxD (presumably with a resistor), and combine the
two calls above to set break, read the switch, and then clear break, you
might have a working solution.

Caveat: I know nothing about hardware, and have destroyed logic boards in
my time; seek qualified medical advice, and I'm not responsible for any
damage you do....

Having said that, the above solution allowed us to make this interface
with
no additional hardware and has been working fine under heavy use on nine
workstations for the last 30 months.

Hope this helps,
Ben

+++++++++++++++++++++++++++

>From [e-mail] (Jim Sokoloff)
Date: Fri, 25 Feb 1994 14:33:53 GMT
Organization: MV Communications, Inc.

I would recommend using the GPIa pin.  Docs for its use are in a Tech note
(something like 283 springs to mind)  Sorry, I worked on this long ago,
before the tech notes got renamed.

If you can't find it, E-mail me and I'll look up the tech note for you.
If you don't have TNs, e-mail and I'll copy the source from the note and
forward it.

---Jim Sokoloff


---------------------------

>From [e-mail]
Subject: WDEF Problems, driving me crazy...
Date: Wed, 23 Feb 1994 09:08:31 GMT
Organization: University of Colorado, Boulder

I have been writing a WDEF for a floating palette and have been running
into very strange erratic behaviour. Inside Macintosh : Toolbox Essentials
doesn't help any with its rather brief and incomplete description of how
to write a WDEF. What I need to know is:

1) How to calculate the strucRgn and contRgn regions. IM:TE says to do
   this 'based on the current graphics port' but somehow I think that's
   wrong.

2) How to retrieve standard window colors from the default color table
   easily. I want my palette to reflect the settings in the Color control
   panel.

3) Which QD commands can be used when drawing a window's contents? I have
   had little success with RGBForeColor() - I usually get totally different
   colors to what I requested.

Any ideas? I would really appreciate any ideas or sample code you might
have.

Nick.

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Wed, 23 Feb 1994 11:47:39 -0600
Organization: I-Link, Ltd.

In article <[e-mail]>,
[e-mail] wrote:

> I have been writing a WDEF for a floating palette and have been running
> into very strange erratic behaviour. Inside Macintosh : Toolbox Essentials
> doesn't help any with its rather brief and incomplete description of how
> to write a WDEF. What I need to know is:

Well, first off, I'm wondering why you chose to write such a WDEF. I have
made and released a WDEF called the Infinity Windoid WDEF that implements
such a window look (if you're looking for a System 7-style floating
window). You can use it for free, and the source is included if you want to
modify any of its behavior.

> 1) How to calculate the strucRgn and contRgn regions. IM:TE says to do
>    this 'based on the current graphics port' but somehow I think that's
>    wrong.

I do the following:

void
GetGlobalMappingPoint(WindowPeek window, Point *thePoint) {
    //    This routine returns a point that gives the horizontal and vertical
    //  offsets needed to map something into global coordinates.
    GrafPtr savePort;

    GetPort(&savePort);
    SetPort((GrafPtr) window);

    SetPt(thePoint, 0, 0);
    LocalToGlobal(thePoint);

    SetPort(savePort);
}

void
GetGlobalContentRect(WindowPeek window, Rect *contentRect) {
    Point mappingPoint;

    *contentRect = window->port.portRect;
    GetGlobalMappingPoint(window, &mappingPoint);
    OffsetRect(contentRect, mappingPoint.h, mappingPoint.v);
}

void
DoWCalcRgns(WindowPeek window, long param) {
    #pragma unused(param)
    Rect theRect;
    RgnHandle tempRgn = NewRgn();

    // -- calculate the content Rect in global coordinates
    GetGlobalContentRect(window, &theRect);
    RectRgn(window->contRgn, &theRect);

    // -- start off with the structure equal to the content
    //    & make it include the window frame and titlebar
    InsetRect(&theRect, -1, -1);
    if (WindData.hasTitlebar) {
        if (WindData.isHoriz)
            theRect.top -= kTitleHeight - 1;
        else
            theRect.left -= kTitleHeight - 1;
    }
    RectRgn(window->strucRgn, &theRect);

    // -- add the shadow to the structure
    OffsetRect(&theRect, 1, 1);
    RectRgn(tempRgn, &theRect);
    UnionRgn(tempRgn, window->strucRgn, window->strucRgn);

    DisposeRgn(tempRgn);
}


> 2) How to retrieve standard window colors from the default color table
>    easily. I want my palette to reflect the settings in the Color control
>    panel.

This is a little more involved. My code has a set of routines that let you
do this in the most compatible way. There are a lot of little things that
need to be handled. For example, if the device the floater is on is 8-bit
but isn't using the System Palette, there might not be enough different
colors available to appropriately do the color tinging. You will see the
System WDEF punts and uses black-and-white in that case. My routines handle
this in a way that is fully compatible with the System WDEF (i.e. when it
reverts to BW, so does mine).

> 3) Which QD commands can be used when drawing a window's contents? I have
>    had little success with RGBForeColor() - I usually get totally different
>    colors to what I requested.

If you want to draw in color, you have to make sure that you're using the
Color Window Manager port. By default, when the WDEF is called, the B/W
Window Manager port is the current port. Of course, you must sync the color
port up with the B/W one, which can be done using code like the following
(which was originally from Macintosh Programming Secrets and modified a
little by me for my WDEF):

void
SyncPorts(void) {
    GrafPtr bwPort;
    CGrafPtr colorPort;

    GetWMgrPort(&bwPort);
    GetCWMgrPort(&colorPort);
    SetPort((GrafPtr) colorPort);

    BlockMove(&bwPort->pnLoc, &colorPort->pnLoc, 10);
    BlockMove(&bwPort->pnVis, &colorPort->pnVis, 14);
    PenPat((ConstPatternParam) &bwPort->pnPat);
    BackPat((ConstPatternParam) &bwPort->bkPat);
}

You should, of course, save the port in your main routine before calling
this, only call it if Color QuickDraw is present (actually, you only need
to call it for drawing calls), and restore the port before returning to the
Window Manager.

> Any ideas? I would really appreciate any ideas or sample code you might
> have.

Like I said before, you really don't have to do all this yourself. I have
already written a WDEF that does it for you. If you want a different look,
you can simply modify my WDEF.

The reason I released it to the public was to provide something I thought
was lacking in a lot of programs (and still is, when I look through a Mac
magazine and see a lot of them still using the bland B/W WDEF for floating
windows).

There are a lot of people using the Infinity Windoid WDEF now, so it has
been well tested (it's on its third public release). It supports System 6,
computers without Color QuickDraw, several different compilation options,
and it's free. What more could you ask for? (Seriously, if it doesn't do
something you think it should, let me know.)

You can always get the latest version of the Infinity Windoid WDEF via
anonymous FTP at the site 'ftp.i-link.com' in the directory '/pub/infsys/'.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
 //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
//    //////________________________________________________________ //

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Wed, 23 Feb 1994 18:48:37 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

I don't know how much research you've put into your floating palette
peliminary background before starting it.  you may already have looked at
the Infinity Windoid WDEF, and others.  But there's some source code on
Apple's ftp for a program called "DTS.Draw" which has a color, picture
menu which tears off.  Once torn off, it becomes a floating palette.

The pictures in the menu/palette are derived from 'cicn' resources.  They
use the 'PICT' button proc of switching to the next higher 'PICT'
resource ID number when clicked on.

You can tap a floater WDEF as the port where you implement your CDEF for
your picture buttons.  As such, a ready-made WDEF may be all that's needed.

I've made floating palettes, just to see how.  All I did was use an
existing WDEF for a floater (Infinity, if the titleBar will show), then
used a CDEF for picture buttons.  I duplicated the appearence and button
opperation (did not tie routines to them) of the MS Word button bar, and
part of the Color It tool palette (for training purposes).

In ResEdit, where you select the procID for the window, I used one of the
"?" ones (user defined) and just hooked up the Infinity WDEF to it (even
though the title bar was under the menu bar).  Then, the hard part (not
really hard, but monotonous) was to set up all the buttons and their
'CTRL' resources.  That "two by two" ID sequencing is quite patience
taxing!  As well as doing all the 'CTRL's twice.

Imagine how it would be for a 256 color palette!  Of course, I did not
get into a lot of refinement and detail.  Maybe there's a more brief
method for such a thing?

All I'm saying is that if there's no difference, really, in the window,
itself, from other WDEFs, then it's the content that would be the main
part of the problem.  And in the case of a palette, it's a CDEF you're
looking at.  And iff it's buttons, then the CDEF is pretty common, too -
it's expanding it to cover all you want it to that's the job.

I made a double button bar for the author of KwikKnowledge (for
MicroPhone II) which had two rows of 64x64 'PICT' buttons.  They appeared
in a standard window.  I just used a 'PICT' button CDEF I downloaded from
AOL, which had 3 buttons.  I just dumped the second two, which were
different, copied the code for the first one, and hit Command-V 13
times.  Then I went back and specified some parts of it.  This was in the
CDEF resource code, itself.  once that was done, in was a matter of
creating and aligning all the 'CTRL' resources, and adding the 'PICT'
resources.  28 of them very monotonous.

A quicker way to do monotonous resource editing is to make one, decompile
that one with ResTools, then make the remaining ones in the text editor.
Works for the "easy to see" resources, like 'ditl's, 'CTRL's, etc.

Does any of this help, or did I miss (again)?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Thu, 24 Feb 1994 04:45:57 GMT
Organization: NETCOM On-line Communication Services (408 241-9760 guest)

Troy's message was not there when I followed up.  His advice is more
sound than mine because he's a professional programmer.  He made the
Color It tool palette.  I assume the color palette, and others, as well.
Awesomely done!  Very aesthetic.

I see that I wrote "CTRL" rather than "CNTL".  My cheap Apple Standard
keyboard is the worse for wear.  Many keys have only a small black spot
where the label was.  But you get the idea - the control resource.

What's the procID of the buttons in the Color It tool palette?  And on
the color palette, how is the selection done there?

-Ken-

+++++++++++++++++++++++++++

>From [e-mail] (Tom Dowdy)
Date: Wed, 23 Feb 1994 20:45:56 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Ken Long)
wrote:
> A quicker way to do monotonous resource editing is to make one, decompile
> that one with ResTools, then make the remaining ones in the text editor.
> Works for the "easy to see" resources, like 'ditl's, 'CTRL's, etc.

Better yet, through creative use of calculations and #defines
you can actually structure layouts such as the one you are talking
about (2X2 CNTL arrays) using Rez.

The real advantage to taking this approach is that when you decide
to change things like the size ("Oh gosh, wouldn't 3X3 be better?")
or the margins, a single change of a #define will get you the results.

GUI based layout apps are really nice for prototyping, but for
bulk work, you can often get faster results via the old-fashioned
text stream based way.

I usually layout the basics with ResEdit, and then DeRez and work
>From there.  As an added bonus, you can structure your resources
to allow for building localized versions of your application
with just a script.

--
 Tom Dowdy                  Internet: [e-mail]
 Apple Computer MS:302-3KS  UUCP: {sun,voder,amdahl,decwrl}!apple!dowdy
 1 Infinite Loop            AppleLink: DOWDY1
 Cupertino, CA 95014
 "The 'Ooh-Ah' Bird is so called because it lays square eggs."

+++++++++++++++++++++++++++

>From [e-mail] (Troy Gaul)
Date: Thu, 24 Feb 1994 11:36:25 -0600
Organization: I-Link, Ltd.

In article <[e-mail]>, [e-mail] (Ken Long)
wrote:

> What's the procID of the buttons in the Color It tool palette?

You're going to hate the answer. :)

We don't use resources for the buttons in the tool grid at all. We could,
we just didn't. They're coded directly into the program. The program knows
the boundry of the tool area in the tool palette, and it knows the size of
a button, so from there it generates the grid of buttons, then, in a simple
'for' loop, it draws each of the buttons that need to be updated.

This let us change defines in the program to change the size of the
buttons. Actually, if I had done it all myself, I don't know if this is the
scheme I wouls have used. When I came into the project, there was already a
black and white cool palette. I simply changed the drawing routines to
handle the nice gray-shaded 3-D effect.

One other reason that we do things programmatically is that the tool
palette in Color It! can be edited by dragging and dropping tools into
spots in the palette (still, I think, one of the coolest features of the
Color It! tool palette, along with the popups for changing tool parameters
-- which, by the way, use a stub MDEF to call back into the program). It
would be possible to do an editable tool palette using controls, just more
work.

> And on the color palette, how is the selection done there?

As for the color palette, all I can say is that you haven't seen anything
yet! ;-)  The color palette in the next version is my design (the one in
the current version is an older design by Tom Pinkerton/Kim Montz), and I
(humbly) think that it's much cooler than the current one.  For the record,
the new one is generated by a drawing routine, into an offscreen GWorld.
Then it's just drawn onto the screen when needed with CopyBits.  The old
one is very similar.

As far as hit testing and current-color hilighting are concerned, these are
also done programmaticly. You see, the hit testing that needs to be done
depends on which type of Color Picker is up, and when a Color Wheel (or
Color Cube) is up, the color is determined by a distance/angle formula in
HSL (or HSB), and this color is then converted to RGB for use in the rest
of the program. When a grid of colors is up, the h and v coordinates of the
hit in the item are turned into a grid index by some simple mod math. The
indicators on the wheel/square require a bunch of extra work with regions
to achieve the effect of not flashing as they move.

_troy
//////// //////___Troy [e-mail]__ //
  //    //       I-Link, Ltd. ; West Des Moines, Iowa                  //
 //    //  //   "Iungo ergo sum." (I-Link, therefore I am.)           //
//    //////________________________________________________________ //

---------------------------

>From [e-mail] (Brad Andrews)
Subject: ZcbFree Goes Negative (Error Number 33)
Date: Mon, 21 Feb 1994 17:17:55 GMT
Organization: Chemical Abstracts Service

This has popped up in the application I am working on, and I am trying
to figure out why.  Does anyone know what kinds of things might
make this happen?  I have plenty of memory, so that is not the issue.

I am expanding the heap according to the logic Apple recommends if
that matters (at the start of the program).

---

Brad Andrews
[e-mail]
All opinions are strictly mine


+++++++++++++++++++++++++++

>From Steve Bryan <[e-mail]>
Date: Wed, 23 Feb 1994 05:15:34 GMT
Organization: Sexton Software

In article <[e-mail]> Brad Andrews,
[e-mail] writes:
>This has popped up in the application I am working on, and I am trying
>to figure out why.  Does anyone know what kinds of things might
>make this happen?  I have plenty of memory, so that is not the issue.

Brad,

Amount of memory available is probably not an issue. When zcbFree becomes
negative that means that memory is being randomly (or not so randomly)
overwritten. Likely suspects might include not checking result codes and
proceeding with calls that depend on earlier calls having succeeded (eg
memory allocations). Another favorite is having your compiler doing a
multiplication with 2 byte integers when you thought it was using 4 byte
integers. The resulting negative number then plays havoc with the routine
that was not expecting it. One of my favorites was having a call to a low
level file system routine that expects ioNamePtr to be set to a sensible
value (like a Str255 variable set aside in the stack). If nothing was
done about (ioNamePtr) you will get unfriendly results even if the result
code looks good. One final suggestion would be if you call DisposHandle
on a handle that has already be disposed. There is an init called
something like Double Trouble which helps track down cases like that.
Steve Bryan                  InterNet: [e-mail]
Sexton Software            CompuServe: 76545,527
Minneapolis, MN                   Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Keith Rollin)
Date: Tue, 22 Feb 1994 20:19:25 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, [e-mail] (Brad
Andrews) wrote:

> This has popped up in the application I am working on, and I am trying
> to figure out why.  Does anyone know what kinds of things might
> make this happen?  I have plenty of memory, so that is not the issue.
>
> I am expanding the heap according to the logic Apple recommends if
> that matters (at the start of the program).

Macintosh Technote ME #8 saith (in part):

"The Memory Manager will trigger an “ID=33” system error when, during some
operation which scans the objects in the heap, it sees that its running
count of free bytes (zcbFree, an internal value) has become negative (an
impossible feat in normal operation). This is nearly always caused by
writing zeros past the end of one of the Memory Manager’s heap blocks
(overwriting and corrupting the next block’s header, making it appear to be
a free block).

"If you get this error, use a debugger (like Macsbug or TMON) when you
attempt to reproduce the error, to check the consistency of the heap up to
the point where the error occurs. You may need to do this repeatedly until
you isolate the operation that is corrupting the heap."

----------------------------------------------------------------------------
Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team
Newton

+++++++++++++++++++++++++++

>From [e-mail] (Matt Mora)
Date: 23 Feb 1994 09:00:41 -0800
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (Keith Rollin) writes:

>----------------------------------------------------------------------------
>Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- TeamNewton
                                         ^^^^^^^^^^^^^^^^^^^^
What's this? Time to sell the Taligent Stock? :-)


Xavier



--
___________________________________________________________
Matthew Xavier Mora                    [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (Devon Hubbard)
Date: Thu, 24 Feb 1994 20:29:05 GMT
Organization: Taligent, Inc.

In article <2kg23p$[e-mail]>, [e-mail] (Matt Mora)
wrote:

> In article <[e-mail]> [e-mail] (Keith Rollin) writes:
>
> >----------------------------------------------------------------------------
> >Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- TeamNewton
>                                          ^^^^^^^^^^^^^^^^^^^^
> What's this? Time to sell the Taligent Stock? :-)
>
> Xavier

Why... do you have Taligent stock?  Gee, I'm jealous?

--------------------------------------------------------------------------
Devon Hubbard                                                Silicon Pilot
[e-mail]                                   Taligent, Inc

---------------------------

>From [e-mail] (Apple-O)
Subject: any good magazines?
Date: 21 Feb 94 08:20:18 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Back in the day, Compute and Compute Gazette had some usefu stuff for learning about programming your computer, with listings of small programs, utiities and other good info.

Are there any such pubications out for the mac? I've been out of programming for a while and would like to start learning using C and the mac.

--
Apollo

+++++++++++++++++++++++++++

>From [e-mail] (Edwin H. Watkeys III)
Date: Mon, 21 Feb 1994 15:52:44 GMT
Organization: Drexel University

In article <[e-mail]> [e-mail] (Apple-O) writes:
>Back in the day, Compute and Compute Gazette had some usefu stuff
for learning about programming your computer, with listings of small
programs, utiities and other good info.

>Are there any such pubications out for the mac? I've been out of
programming for a while and would like to start learning using C and the mac.

Compute was a lot better at teaching you how to type than how to program.
Some of those things look like they came out of some Obfuscated BASIC
Programming Contest. In addition, Compute almost always sucked if you
cared about the Apple II or Macintosh. They had more VIC-20 programs than
Apple II ones! I hate them. They dedicated most of the damn issue to
Commodore crap, and they had another magazine (Compute Gazette) dedicated to
even more Commodore crap. I don't understand it. Talk about bad taste in
computers! I can hardly contain my indignation even today towards people who
put in the same league the Commodore 64 and the Apple IIe.

But to be constructive for a bit, MacTech Magazine (formerly MacTutor) is
the Mac developers' magazine. Not "the" as in "the best", but as in "the
only". There's stuff in there aimed at all sorts of experence levels.
Yeah, but how many hit points do you have? Ugh! Don't get me started on that!

However, you might want to buy a few books instead. It's doubtful that it's
going to take you a month to digest whatever's in Dave Mark's column.
You'll be spending a lot of time waiting for the new MacTech to come out.
I find myself reading anything in English inside MacTech. Hmm, did you
know their person in charge of circulation is Al Estrada? You know, you go
crazy... Remember the part in The Treasure of the Sierra Madre where
Bogart starts laughing like a mad man as his head is engulfed in the
campfire's flames? Like that...

Macintosh C Programming Primer Volume I, SECOND EDITION, is pretty good.
Buy it. Macintosh Programming Secrets, SECOND EDITION, ranks right up
there with The Big Book of Hell in my list of all time favorite
technical/reference works. Buy it (Macintosh Programming Secrets, that is).

And by the way, C is a good choice, because C is the only language you can
program the Mac in these days unless you're like Peter Lewis, who has
displayed uncommon courage in his battle to use a non-discipline-free
programming language, Pascal. I used to hate C and love Pascal. Now I
resigned to C and forget how all that pointer stuff works in Pascal. Isn't
life great?

I was just thinking -- WriteNow is really nice because it's written in
assembly, but with the Power Macintoshes coming out, they'd be in a better
position if their code was in C. "Better" is a mild way of putting it.
RightNow, they're screwed... (get it? hahahahaha!!!)

Get me the oxygen mask...ahh,
Ed
--
Ed Watkeys              [e-mail]  Drexel University
Philosopher-Programmer  [e-mail]           Distant Software
                        - Use finger for my PGP key. -

+++++++++++++++++++++++++++

>From [e-mail] (Jude Giampaolo)
Date: 21 Feb 1994 16:45:12 GMT
Organization: WSOM CSG, CWRU, Cleve., OH, 44106, USA

In article <[e-mail]> [e-mail] (Edwin H. Watkeys III) writes:
>In article <[e-mail]> [e-mail] (Apple-O) writes:
>>Back in the day, Compute and Compute Gazette had some usefu stuff
>for learning about programming your computer, with listings of small
>programs, utiities and other good info.
>
>>Are there any such pubications out for the mac? I've been out of
>programming for a while and would like to start learning using C and the mac.
>
>Compute was a lot better at teaching you how to type than how to program.
>Some of those things look like they came out of some Obfuscated BASIC
>Programming Contest. In addition, Compute almost always sucked if you
>cared about the Apple II or Macintosh. They had more VIC-20 programs than
>Apple II ones! I hate them. They dedicated most of the damn issue to
>Commodore crap, and they had another magazine (Compute Gazette) dedicated to
>even more Commodore crap. I don't understand it. Talk about bad taste in
>computers! I can hardly contain my indignation even today towards people who
>put in the same league the Commodore 64 and the Apple IIe.

Commodores were the greatest machines! I still have mine, wonderful
little game box. The c64 was a much better (and cheaper) machine out
of the box than any of the Apple IIs ever were. IMHO of course... :)



--
Jude Charles Giampaolo           -  Case Western Reserve University
Electrical Engineering           -                  Cleveland, Ohio
and Applied Physics              -  [e-mail]
Project Caffeine Programmer      -                 [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: 22 Feb 1994 11:32:58 +0800
Organization: NCRPDA, Curtin University

[e-mail] (Apple-O) writes:

>Back in the day, Compute and Compute Gazette had some usefu stuff for
>learning about programming your computer, with listings of small programs,
>utiities and other good info.

Well, I dont know about a magazine, it doesn't have any adds or anything,
but Develop is a very good programmers mag.  Its fairly technical
(pleasant change) and informal (ditto), but it also comes with a CD
that has all the NIM stuff on it, so its very useful to get.  Plus its
pretty reasonably priced (US$50 for international, so it must be less for
US people).

Now if I ever get my first copy, I'll be even happier...
   Peter.
--
_______________________________________________________________________
Peter N Lewis <[e-mail]>       Ph: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Shawn O'Donnell)
Date: 22 Feb 1994 19:26:03 GMT
Organization: Massachusetts Institute of Technology

I'd give a thumbs down to MacTech Magazine--its useful-things-you-might-
learn-to-price ratio is too high.  In a good month, you'll get a useful
Dave Mark column and maybe another article that's useful for someone
trying to use C on the Mac.  At $4.00 subscription price, $5.85
newsstand price, that's a lot per page of useful stuff.

On the other hand, if someone else is paying, or if you need to see the
ads for all the development tools, then it might make sense.

Instead, buy any book about programming the Mac with Knaster as an
author.  Buy one by Dave Mark if you want a more introductory look at C
programming on the Mac.  Or that one by Sydow: Think THINK C.

--Shawn

+++++++++++++++++++++++++++

>From [e-mail] (Scott T Boyd)
Date: Thu, 24 Feb 1994 10:15:04 GMT
Organization: MacTech Magazine

<sorry if this is a repost, my connection dropped while sending the first
time>

In article <[e-mail]>, [e-mail] (Shawn
O'Donnell) wrote:
>
> I'd give a thumbs down to MacTech Magazine--its useful-things-you-might-
> learn-to-price ratio is too high.  In a good month, you'll get a useful
> Dave Mark column and maybe another article that's useful for someone
> trying to use C on the Mac.  At $4.00 subscription price, $5.85
> newsstand price, that's a lot per page of useful stuff.

Well, funny you should mention that.

<----Warning, blatant plug for the magazine is about to happen---->

Dave Mark's columns generate a lot of mail.  Some people wonder why we
carry what they consider to be such rudimentary articles.  Lots more
praise his work for easing them gently into Macintosh programming without
being overwhelmed with complexity.

What can you do? Improve it all, that's what.  We're working on that,
and that's why they recently brought me on as Editor.  I'll be working to
improve the good-stuff-to-price ratio.

To give you something of an idea, we're covering PowerPC technical issues,
including debugging tips and tricks, details of the PEF file structure,
calling 68K code from PowerPC code, as well as doing reviews of recent
developments in a wide variety of tools and development environments.

You can help.  Write me and let me know what you like, don't like,
and what you'd like to see us cover.  I get a lot of mail already, so I'm
not going to promise to reply to everything, but I'll make a good faith
effort to read everything, and reply when I can.  Don't be surprised if
a change or idea you suggest winds up in the magazine.

Even better, write an article for us.  A good, meaty, technical article in
the useful-things-you-might-learn category.  Send me a note with an outline
of something you'd like to write about, and we can take it from there. Tips
and tricks of the trade are also quite welcome.

> On the other hand, if someone else is paying, or if you need to see the
> ads for all the development tools, then it might make sense.

Yes, there is a lot of good information in the ads, and we're working to
bring you even more interesting things.

Please feel free to let us know how we're doing.  You, the reader, are
the audience we're hoping to please.

Regards,
scott t boyd
(the new) Editor, MacTech Magazine
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************